1.3 Assemblies 

Das Ergebnis der Kompilierung von .NET-Quellcode ist eine Assembly. Bei der Kompilierung wird, abhängig davon, welchen Projekttyp Sie gewählt haben, entweder eine EXE- oder DLL erzeugt. Wenn Sie nun in diesen Dateien ein Äquivalent zu den EXE- oder DLL-Dateien sehen, die Sie mit Visual Basic 6.0 oder C/C++ erzeugt haben, liegen Sie falsch – beide sind nicht miteinander vergleichbar.

Assemblies liegen im IL-Code vor. Zur Erinnerung: IL bzw. MSIL ist ein Format, dass erst zur Laufzeit einer Anwendung vom JITter in nativen Code kompiliert wird. Eine Assembly kann nicht nur eine, sondern auch mehrere Dateien enthalten – eine Assembly ist daher eher als die Baugruppe einer Anwendung zu verstehen.

Assemblies liegen, wie auch die herkömmlichen ausführbaren Dateien, im PE-Format (Portable Executable) vor, einem Standardformat für Programmdateien unter Windows. Das Öffnen einer PE-Datei hat zur Folge, dass die Datei der Laufzeitumgebung übergeben und als infolgedessen ausgeführt werden. Daher wird Ihnen beim Starten auch kein Unterschied zwischen einer Assembly und einer herkömmlichen Datei auffallen.

1.3.1 Die Metadaten 

Assemblies weisen eine grundsätzlich neue, andersartige Struktur auf. Assemblies enthalten nämlich nicht nur IL-Code, sondern auch sogenannte Metadaten. Die Struktur einer kompilierten .NET-Komponente gliedert sich demnach in

IL-Code und

Metadaten

Metadaten sind Daten, die eine Komponente beschreiben. Das hört sich im ersten Moment kompliziert an, ist aber ein ganz triviales Prinzip. Nehmen wir an, Sie hätten die Klasse Auto mit den Methoden Fahren, Bremsen und Hupen entwickelt. Wird diese Klasse kompiliert und der IL-Code erzeugt, lässt sich nicht mehr sagen, was der Binärcode enthält und vor allem, wie er genutzt werden kann. Wenn eine andere Komponente auf die Idee kommt, den kompilierten Code eines Auto-Objekts zu nutzen, steht sie vor verschlossenen Türen.

Das Anbinden der Metadaten an den IL-Code ist wie ein Inhaltsverzeichnis zu verstehen: Man sucht unter einem Stichwort im Inhaltsverzeichnis nach einem bestimmten Begriff, findet eine Seitenzahl und kann zielgerichtet im Buch das gewünschte Thema nachlesen. Viel mehr machen die Metadaten eines .NET-Kompilats auch nicht, wenn auch die Funktionsweise naturgemäß etwas abstrakter ist: sie liefern Objektinformationen, beispielsweise die Eigenschaften eines Objekts und die Methoden. Das geht sogar soweit, dass wir über die Metadaten in Erfahrung bringen, wie die Methoden aufgerufen werden müssen.

Das grundsätzliche Prinzip der Aufteilung in Code und Metadaten ist nicht neu und wurde auch schon unter COM angewandt. Allerdings mit einem kleinen, aber doch sehr wesentlichen Unterschied: COM trennt Code und Metadaten. Die Metadaten einer COM-Komponente, die man auch als Typbibliothek bezeichnet, werden in die Registry eingetragen und dort ausgewertet. Das ist nicht gut, denn schließlich sollten Sie Ihren Personalausweis immer bei sich tragen und ihn nicht irgendwo hinterlegen. Ebenso sollte auch der Code nicht von seinen Metadaten getrennt werden. COM ist dazu nicht in der Lage: Erst innerhalb des .NET Frameworks wird dieser fundamentalen Forderung einer untrennbaren Selbstbeschreibung Rechnung getragen.

Die Metadaten versorgen die .NET-Laufzeitumgebung mit ausreichenden Informationen zum Erstellen von Objekten, zum Aufruf von Methoden und Eigenschaften. Sie bilden eine klar definierte Schnittstelle und vereinheitlichen den Objektzugriff, was allen .NET-Entwicklern zugute kommt: Unabhängig von der Sprache – vorausgesetzt, sie ist .NET-konform – können problemlos Objekte verwendet werden, die von anderen Entwicklern bereitgestellt werden. Dass die Objekte in einer beliebigen .NET-Sprache entwickelt worden sein können, braucht fast nicht erwähnt zu werden.

1.3.2 Das Manifest 

Die Folgen der Trennung von Code und Selbstbeschreibung einer COM-Komponente sind uns wahrscheinlich allen bewusst: Durch die Installation einer neuen Anwendung werden alte COM-Komponenten überschrieben, die für andere Anwendungen von existentieller Bedeutung sind. Die Auswirkungen können fatal sein: Eine Anwendung, die auf die Methoden der überschriebenen Komponente zugreifen will, kann sich im schlimmsten Fall mit einem Laufzeitfehler sang- und klanglos verabschieden.

Mit Assemblierungen gehören diese Fehler definitiv der Vergangenheit an. Verantwortlich dafür sind Metadaten, die nicht die einzelnen Objekte, sondern die Assemblierung als Ganzes beschreiben. Diese werden als Manifest bezeichnet. Ein Manifest enthält die folgenden Informationen:

Name und Versionsnummer der Assembly

Angaben über andere Assemblierungen, von denen die aktuelle Assembly abhängt

die von der Assembly veröffentlichten Typen

Sicherheitsrichtlinien, nach denen der Zugriff auf die Assembly festgelegt wird

Das Manifest befreit eine Assembly von der Notwendigkeit, sich in die Registrierung eintragen zu müssen. Die logischen Konsequenzen gehen sogar noch weiter: Während sich COM-Komponenten erst durch eine Setup-Routine oder zusätzliche Tools in die Registrierungsdatenbank eintragen, können Sie mit den primitivsten Copy-Befehlen eine Assemblierung in ein beliebiges Verzeichnis kopieren – Altbewährtes ist manchmal doch nicht so schlecht.